home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-noop-tools-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
21KB
|
726 lines
DRAFT - Tools RFC
S. Hares and C. Wittbrodt
November 10, 1992
Draft - TOOLS RFC November 10, 1992
1. Status
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material or
to cite them other than as a "working draft" or "work in
progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
This Internet Draft specifies tools which are necessary to
debug problems in the deployment and maintenance of networks
using ISO 8473[1], the connectionless network layer protocol
(CLNP). This document will be submitted to the RFC editor as
a proposed standard for the OSI Internet.
To support some of the needed tools (ping and traceroute)
this draft specifies the mechanism specified in RFC1139 [2].
RFC 1139 is intended to mirror the work that is currently
going on within the ISO community. ISO work is progressing
on an ISO echo function, but not completed yet and at this
time, there is no estimated date of completion. A revised
RFC 1139 reflects the current RFC's work [3].
2. Abstract
This draft specifies the following three necessary tools to
debug problems in the deployment and maintenance of networks
using ISO 8473 (CLNP):
- ping or ISO Echo function
- traceroute function which uses the ISO Echo function
- routing table dump function
Expires May 10, 1993 Page 2
Draft - TOOLS RFC November 10, 1992
3. Table of Contents
1 Status ...................................... 2
2 Abstract .................................... 2
3 Table of Contents ........................... 3
4 Introduction ................................ 3
5 Specification ............................... 4
5.1 Ping ...................................... 4
5.1.1 Protocol Support ........................ 4
5.1.2 Functions supported by the ping utility . 5
5.2 Traceroute ................................ 5
5.2.1 Basic Traceroute ........................ 5
5.2.2 Use of Partial Source route in traceroute 7
5.2.3 Information needed from a Traceroute
utility ................................... 7
5.3 OSI routing table dump .................... 8
5.3.1 SNMP .................................... 8
5.3.1.1 RFC XXXX Integrated IS-IS MIB [6] ..... 9
5.3.1.2 RFC XXXX IDRP MIB [7] ................. 9
5.3.2 CMIP agent .............................. 9
5.3.2.1 ISO 10733 (Network Layer Management
info) [8] ................................. 9
5.3.2.2 ISO 10589 (IS-IS Management
info) [9] ................................. 10
5.3.2.3 ISO 10747 (IDRP Management info) [4]
........................................... 10
6 References .................................. 11
4. Introduction
Currently in the Internet, OSI protocols are being used more
and more. As the network managers of an Internet once
predominantly a TCP/IP network began deploying parts of the
emerging OSI Internet, it became apparent that network layer
ISO network debugging tools were almost nonexistant. When
such tools existed, different implementations didn't work
together.
As stated in RFC 1139 a simple network layer mechanism is
necessary to allow systems to be probed to test network
layer integrity. RFC 1139 goes on to describe two different
ping capabilities, one a long term solution, and one a
short term solution. The problem becoming more and more
prevalent in the OSI Internet is that some vendors imple-
mented the short term solution and some implemented the long
term one. The two solutions do not work together, i.e., a
ping from a host with the short term version to one with the
long term version will not work, and visa versa. Also,
some hosts and routers have not implemented a ping at all.
The two solutions provided to simplify the situation, have
Expires May 10, 1993 Page 3
Draft - TOOLS RFC November 10, 1992
instead complicated it. The revised version of RFC 1139
specifies only the long term solution. Certain wording in
the error handling section have been revised to match the
current ISO work.
5. Specification
This document's purpose is to specify a standard ping, tra-
ceroute, and OSI routing table dumping mechanisms for use
for the ISO 8473 (CLNP) protocol in the OSI Internet. A
detailed description of the specified mechanisms is below.
These mechanism should be available on every router (inter-
mediate system) or host (end system) that provides OSI ser-
vice for the Internet. These three functions are the basic
tool set for the OSI network layer for the Internet.
5.1. Ping
5.1.1. Protocol Support
The long term echo mechanism, as described in RFC1139,
requires the use of two new type values in the packet header
of the ISO 8473 Network Protocol Data Units(NPDUs). The two
values are:
1E(hex) - for the Echo Request Selector and,
1F(hex) - for the Echo Reply Selector.
Nodes which support ISO8473 but do not support these two new
values (for the type code option field in the header of an
ISO 8473 (NPDU) will send back an error packet IF the ERROR
report flag is set in the NPDU.
To support a ping function for ISO 8473, all end systems
(hosts) and intermediate systems (routers) must support the
"long term" echo function as defined by RFC 1139-Revised AND
also set the ERROR report flag in the 8473 header.
The setting of the ERROR report flag is required because
this allows a way for a compliant host or router to ping a
non-compliant host or router. When a non-complaint host or
router receives a "ping" NPDU with the new type function
(Echo Request Selector), it will send back an ISO 8473 ER
NPDU to the originating host, thus showing reachability.
Expires May 10, 1993 Page 4
Draft - TOOLS RFC November 10, 1992
5.1.2. Functions supported by the ping utility
A ping utility should able to provide the Round trip time of
each packet, plus the average minimum and maximum RTT over
several ping packets. When an ER NPDU is received by the
node, the ping utility should report the error code to the
user.
5.2. Traceroute
The CLNP trace is similar to the ping utility except that it
utilizes the "Lifetime" field in the ISO 8473 NPDU. The
"Lifetime" field serves the same function as the Time To
Live (TTL) field does in an IP packet. A node (router or
host) cannot forward ISO 8473 NPDU with a value for the
Lifetime of zero. If the ERROR REPORT flag is set in the
ISO 8473 PDU, an ER (error) NPDU will be returned to the
originator of the packet.
5.2.1. Basic Traceroute
If a ISO 8473 PDU with a type code of Echo-request is sent
with "Lifetime" field value of 1, the first hop node
(router or end system) will either return an ER NPDU to the
originator the NPDU. If the first hop node supports the
"Echo-Request" type field the error code will be either:
A0 (hex) - Lifetime Expired while Data Unit in Transit
A1 (hex) - Lifetime Expired during Re-assembly
If the first hop node does not support "Echo-Request" type
field, the Error code will be:
B0 (hex) - Unsupported Option not Specified.
When trying to trace a route to a remote node, the destina-
tion address in the Echo-Request PDU sent should be this
remote destination. By using increasing values in the
"Lifetime" field a route can be traced through the network
to the remote node. This traceroute function should be
implemented on each system (host or router) to allow a user
to trace a network path to a remote host or router.
The error message is used as evidence of the reachablity and
identity of the first hop. The originator then sends a
packet with a "lifetime" field value of 2. The first hop
decrements the "Lifetime" and because the "Lifetime" is
Expires May 10, 1993 Page 5
Draft - TOOLS RFC November 10, 1992
still greater than 0, it forwards it on. The second hop
decrements the "Lifetime" field value and sends an Error PDU
(ER NPDU) with one of the two "Lifetime Expired" error
codes listed above to the originator. This sequence is
repeated until either:
- the remote host is reached an either an Echo-Reply PDU is sent
back or (for nodes that do not have the required Echo support)
an ER PDU is sent back, or
- the an ER PDU is received with error code (B0) indicating
that a node will not pass the Echo-Reply packet, or
- an ER NPDU is received with one of the following errors:
80(hex) - Destination Address Unreachable
81(hex) - Destination Address Unknown.
If any of the following Error codes are received in an ER
PDU, a second PDU should be sent by the originating node:
CodeReason from 8473
-----------------------------
00(hex) - Reason not specified
01(hex) - Protocol procedure error
02(hex) - Incorrect checksum
03(hex) - PDU Discarded due to Congestion
04(hex) - Header Syntax Error (cannot be parsed)
05(hex) - Segmentation needed but not permitted
06(hex) - Incomplete PDU received
07(hex) - Duplicate Option
B1(hex) - Unsupported Protocol Version
B2(hex) - Unsupported Security Option
B3(hex) - Unsupported Source Routeing Option
B4(hex) - Unsupported Recording of Route Option
C0(hex) - Reassembly Interface
If one of these error is detected, an error value should be
returned to the user. More than one Echo NPDU, may be
sent at a "Lifetime" value. The number of additional echo
NPDUs is left up to the implementation of this traceroute
function.
If one of the following errors is received, AND "partial
source route" is not specified in the Echo-Request NPDU,
send a second Echo-Request NPDU to the destination at a
"Lifetime" value:
Expires May 10, 1993 Page 6
Draft - TOOLS RFC November 10, 1992
Code Reason from 8473
--------------------------------
90(hex) Unspecified Source Routeing Error
91(hex) Syntax Error in Source Routeing Field
92(hex) Unknown Address in Source Routeing Field
93(hex) Path not Acceptable
(The Echo-request NPDU may have been damaged in shipping
through the network.)
5.2.2. Use of Partial Source route in traceroute
The current IP traceroute has a 3rd party or "loose source
route" function. The ISO 8473 protocol also supports a
"partial source routeing" function. However, if a node
(router or host) does not support the "partial source route-
ing" function an ISO 8473 NPDU gets passed along the path
"exactly as though the function has not been selected. The
PDU shall not be discarded for this reason."[2]
A partial source route function in the ISO Traceroute will
set in the option fields the "source routeing" option, and
the "partial source routeing" parameter within that option.
To support a 3rd party or "loose source route" traceroute
function, a node will send the Echo-Request NPDU with the
"loose source routeing" field set. The functioning of the
3rd party/"loose source route" traceroute is the same except
the following error cause the traceroute to be terminated:
Code Reason from ISO 8473
--------------------------------------------------
92 Unknown Address in Source Routeing Field
93 Path not Acceptable
These errors may indicate a problem with the "loose source
route" listed in the Echo-Request NPDU for this destination.
Additional NPDUs with the same lifetime will only repeat
this error. These errors should be reported to the user of
the traceroute function.
5.2.3. Information needed from a Traceroute utility
A traceroute utility should provide the following informa-
tion to the user:
Expires May 10, 1993 Page 7
Draft - TOOLS RFC November 10, 1992
- NET of systems the pathway goes through,
- ping times (in Round trip times) for each
hop in the path,
- error codes from ER PDU received as a
response to the an Echo-Request packet, and
- any other error conditions encountered
by traceroute.
5.3. OSI routing table dump
Each OSI host (end system) or router (intermediate system)
needs to be able to dump any of its routing tables. Routing
tables may come from the:
a.) the ES-IS information
b.) static
c.) IS-IS
d.) IDRP
or any other source.
Each system must be able to dump the routing table entries
via some out of band mechinism. A method must exist to pro-
vide these. It is suggested that a show osi routes command
be created with the following options:
- a for all routes
- esis for es-is routes
- isis for is-is routes
- idrp for idrp routes
- static for static routes
- other for routes from other sources.
In addition, it is optional but highly recommended that the
routing tables be available via of the following network
protocols:
5.3.1. SNMP
Expires May 10, 1993 Page 8
Draft - TOOLS RFC November 10, 1992
Internet MIBs
RFC 1238 CLNS MIB [5]
NET of this router
ES adjacencies,
ES Connection Timer,
ES hold timer
IS Adjacencies
5.3.1.1. RFC XXXX Integrated IS-IS MIB [6]
IS Reachability information
IS L1 Adjacencies
IS L2 ADjacencies
5.3.1.2. RFC XXXX IDRP MIB [7]
per BIS router:
InternalBIS,
IntraIS,
ExternalBISNeighbor,
Internal Systems,
LocalRDI,
RDC-Config,
Local-SNPA,
MultiExit,
RouteServer
holdTime,
CloseWaitDelay
Local RIB
Local FIB
per BIS neighbor:
BIS NET
BIS RDI
BIS RDC
Adj-RIB information
5.3.2. CMIP agent
5.3.2.1. ISO 10733 (Network Layer Management info) [8]
Expires May 10, 1993 Page 9
Draft - TOOLS RFC November 10, 1992
Network Entity Managed Object
networkEntityTitles
linkage-ISO9542ES-P
HoldingTimerMultipler
manualISSNPAAddress
defaultESConfigTimer
activeESConfigTimer
isReachabilityChanges
linkage-ISO9542IS-P
holdingTimerMultiplier
isConfigurationTimer
suggestedESConfigurationTimer
redirectHoldingTimer
eSReachabilityChanges
5.3.2.2. ISO 10589 (IS-IS Management info) [9]
IS Reachability information
IS L1 Adjacencies
IS L2 ADjacencies
5.3.2.3. ISO 10747 (IDRP Management info) [4]
per BIS router:
InternalBIS,
IntraIS,
ExternalBISNeighbor,
Internal Systems,
LocalRDI,
RDC-Config,
Local-SNPA,
MultiExit,
RouteServer
holdTime,
CloseWaitDelay
Local FIB
Local RIB
per BIS neighbor:
BIS NET
BIS RDI
BIS RDC
Adj-RIB information
Expires May 10, 1993 Page 10
Draft - TOOLS RFC November 10, 1992
6. References
[1] ISO/IEC 8473, Information Processing Systems, "Protocol
for Providing the Connectionless-mode Network Service and
Provision of Underlying Service". May, 1987.
[2] R. Hagens, "An Echo Function for ISO 8473", Request For
Comment #1139, January 1990. DDN Network Information
Center, SRI International.
[3] R. Hagens and C.Wittbrodt, "An Echo Function for ISO
8473", Request For Comment #1139-Revised, October 1992.
DDN Network Information Center, SRI International.
[4] ISO/IEC DIS 10747 Information Processing Sys-
tems - Telecommunications and Information Exchange
between Systems - Protocol for Exchange of Inter-domain
Routeing Information among Intermediate Systems to Support
Forwarding of ISO 8473 PDUs.
[5] RFC 1238 CLNS MIB (Greg Satz) - for use with Connec-
tionless Network Protocol (ISO 8473) and End system to
Intermediate System Protocol (ISO 9452)
[6] RFC xxx Integrated IS-IS MIB - (Chris Gunner)
[7] RFC xxxx IDRP MIB (Hares)
[8] ISO/IEC 10733 - Information Technology - Telecommuni-
cations and Information Exchange between Systems - Elements
of Management Information Relating to OSI Network Layer
Standards
[9] ISO/IEC 10589 - Information Processing Sys-
tems - Telecommunications and Information Exchange
between Systems - Protocol for Exchange of Intra-Domain
Routeing Information among Intermediate Systems.
Expires May 10, 1993 Page 11